Passphillance Eher referring place

Moment von Crunch

Schritten oder ein Schichten gegen Kartmericen

queer und Royal

itten oder an même h explosion

aus der

Clock

ein

Le Ding

suis

tool

und

vom

nicht vermeiden und werden auch zur Laufzeit im Betrieb auftreten, müssen wir uns auch um jene

Situation kümmern, wo eine Software zum Beispiel sicherheitskritisch etwas betreibt und dann nicht

einfach wegen eines Fehlers crashen darf, sondern wir müssen als Teil der normalen Programmierung

mit aufnehmen, dass man eben auch Fehler erlebt und dass man in eine entsprechende Fehlerbehandlung

gehen sollte. Hier sehen Sie ein Beispiel für etwas, was ich als schlechten Code,

insbesondere im Hinblick auf die Fehlerbehandlung sehen würde. Schauen wir also mal drauf,

was hier geschieht und identifizieren Sachen, die vielleicht Ihnen schon so intuitiv aufstoßen.

Wir sehen hier also eine Methode readInt. Offensichtlich wird wohl ein Integer aus einer

Datei gelesen. Diese Methode gibt den Integer zurück, vermutlich das Ergebnis, kann auch

eine parseException, also eine Ausnahme werfen. Was sehen Sie denn hier, was vielleicht nicht

ideal oder nicht so guter Code wäre? Also es gibt hier gleich zu Beginn den Versuch,

halt die Daten zu lesen und Sie sagen halt, hier sind schon mal zwei schlechte Programmierpraktiken,

nämlich einmal alles an Exception aufzufangen und dann den offenkundigen vorliegenden Fehler

oder Ausnahme, über die man hier benachrichtigt wird, einfach zu ignorieren mittels doNothing.

Sicherlich richtig, in sehr gutem Code müsste man hier differenzieren, was es denn für Probleme

gibt und sie ganz bestimmt nicht unter den Tisch fallen lassen. Okay, dann gibt es dann

auch noch den Bezug zu die Methonsignatur, macht gar keinen Sinn, weil hier alles abgefangen wird.

Was fällt Ihnen noch auf? Man hat hier also eine Fehlerbehandlung innerhalb der Methode,

das an sich ist noch nicht so schlecht. Die Frage ist nichtsdestotrotz, wird das lokal behandelt

oder muss der Kontext benachrichtigt werden über den Fehler? Das ist also debattierbar. Sicherlich

schlecht ist hier so ein klassisches System auf Printline, das macht man vielleicht beim Debugging,

wenn man initial was testet, aber in echten Produktivcode nutzt man erstens einen Logger,

zweitens nimmt man sicherlich mal mehr Informationen, als irgendwas hat nicht funktioniert und dann ist

auch wieder die Frage, was man hier noch als drittes nennt, Fehlercode, auch ein Minus 1,

also noch nicht mal inhaltlich benannt und identifiziert, sondern einfach nur irgendwas

ist falsch, dafür steht Minus 1 häufig zurückgibt. Während unklar ist, ist Minus 1 ein valider

Rückgabewert oder nicht. Vermutlich ist hier gedacht, steht aber nirgendswo, dass nur Werte 1 und 0,

also größer 1, größer gleich 1 gültige Rückgabewerte sind. Genau, so weit Sachen,

die hier nicht so richtig gut sind. Und das sieht man als Programmierer, da ist man auch genervt und

wir wollen uns heute halt anschauen, wie man das eigentlich sauberer und anders strukturieren sollte.

Also was hatte ich hier? Aus der Perspektive Design by Contract, Vorbedingungen sind unklar,

keine Zusicherung, keine Klassenvariable. Eine Bacher-Variable war da, die überhaupt nicht

gebraucht wurde. Dann gab es eine Ressource, die genutzt wird, die aber nicht aufgeräumt wird.

Ich glaube, das war hier der Fall Input Stream, der wird nicht wieder entfernt. Es gibt es Garbage

Collection in Java, aber es ist nicht klar, ob zusätzlich dranhängende Ressourcen nicht

wieder freigegeben werden müssen. Garbage Collection kann auch nicht alles sauber ausführen.

Und dann eben spezifisch für die Fehlerbehandlung. Der Rückgabewert war halt überladen mit dem minus